Royal Military College of Canada

Department of Electrical and Computer Engineering

CSL Logo   



EEE466 - Distributed Applications
Hosted by RMC Computer Security Lab (CSL)
Department of Electrical and Computer Engineering

Lab 5

Man-in-the-middle Attacks - ARP Spoofing/TCP Hijacking

References

  1. WinDump Manual
  2. Ettercap README
  3. tcpdump Manual

Introduction

In this lab you will examine some of the security flaws in existing network protocols.  Our currently used suite of network protocols, commonly implemented in the TCP/IP protocol stack on contemporary computer systems, was designed in an environment of trust.  Communicating network machines were trusted not to lie about who they are or subvert the communications on the network. In our current global internet environment this trust does not hold because the attackers are in control of some of the machines on the network. In this lab we will see how the attacker can manipulate packets and lie about who he is. Manipulation of the network can occur at any of the network layers of the OSI model. In this lab we will manipulate information in the link layer, internet layer, and the transport layer. These manipulations will allow us to eavesdrop, redirect communications and hijack TCP sessions. A dated, but illustrative, hacking tool will be used to perform the packet manipulations and you will capture and analyze the resulting traffic in order to better understand how the network vulnerabilities are being exploited.

Part 1 - Explanation of ARP Spoofing and TCP Hijacking

The Address Resolution Protocol (ARP)

Recall the description of ARP from class and Lab 2.

In addition to specifically asking for a MAC/IP mapping when a machine needs to send a network packet, it also listens to all the other ARP traffic on the network. By "listening-out" to ARP traffic in this way a machine can come to know even more MAC/IP address mappings and store them in its ARP cache. In this way the machine may not have to delay a network communication while it makes an ARP request; it already discovered the mapping by listening-out. This scheme is called "Gratuitous ARP". These updates are done even for IP addresses that are already in the ARP cache.

You can see that in order to populate its ARP cache a machine trusts the senders of the ARP messages not to lie. An attacker can craft false ARP packets and cause a machine to alter the mappings in its ARP cache. In this way the attacker can convince the target machine to send packets anywhere he wishes to. This is called "ARP spoofing" or "ARP Cache Poisoning."

TCP Hijacking

If an attacker can monitor an ongoing TCP connection he has access to all the information in the IP and TCP headers and to the packet payloads.  Of course the attacker can eavesdrop on the connection, but by gathering the right information the attacker can actually take over the connection (hijack it).  To do this the attacker needs to know the IP addresses and port numbers the connection is using. He also needs to know the sequence numbers in the TCP headers that are being used to control the error correction mechanisms in the TCP stream communication. Recall that there is an incrementing series of sequence numbers (a different set of numbers for each direction of communication) that are used to make sure: that all packets are being received at the destination, that the packets are reassembled in the correct order, and that duplicated packets are only used once. During synchronization (the initial TCP 3-way handshake) a random sequence number is chosen as the starting sequence number for each direction of the communication. As data is passed on the TCP connection the sequence numbers reported in each packet are incremented to indicate the number of bytes of data passed on the connection up to the point of that packet's transmission. The sequence numbers are used to sort out the order of packets (and discover missing packets) at the other end.

Since the attacker is eavesdropping on the network he has all the information he needs to craft a false packet that looks like it is the next packet in the TCP connection. For example if a user is running a telnet session and logged into a remote computer the attacker can craft packets to send his own commands to the remote machine. The packets will look like, and be executed as if they came from the legitimate user. This is a "TCP Simple Hijack."

A TCP simple hijack has some problems. It works fine for the first hijacking packet but not for more. When the attacker sends his packet he increments the sequence numbers in the normal way so the packet is accepted properly at the destination. Unfortunately the original user's machine is not aware of the hijacking data that was falsely sent and its sequence numbers are still at the old values. When the destination machine acknowledges the false packet the original user's machine sees an acknowledgment for data that it never sent (the data was sent by the attacker). The sequence numbers are now out of synchronization between the legitimate user's machine and the remote host (destination machine). Different operating systems deal with this in different ways but there is danger of a continuous steam of ACK packets being passed back and forth between the machines as they hopelessly try to resynchronize. This is called an "ACK Storm" and can hang the systems.

Now, if we combine this TCP hijacking technique with the ARP spoofing techniques in the previous section we can solve the ACK Storm problems and inject characters into the TCP stream, or take total control of the TCP connection.  The attacker uses ARP spoofing to have the legitimate user's machine and the remote host both send their packets to his attacking machine, instead of their correct destinations. The attacker is now a man-in-the-middle. He controls all the packet flow between machines. Initially, before the hijack, the attacker can simply forward the messages to their correct destination.

However, when he wants to inject packets the attacker can send crafted packets to one of the target machines. The crafted packets will spoof the correct sequence numbers so they will be accepted by the target machine. After this point the sequence numbers in the original two target machines will be out of sync when they communicate; one machine has received more data than the other machine has sent. Therefore the attacking machine as man-in-the-middle must modify the sequence numbers on-the-fly as they pass through to adjust them and keep the target machines in synchronization.

To completely take over the connection, the attacker stops forwarding packets for the legitimate user's machine associated with the hijacked TCP connection. The attacker now fully takes the place of the legitimate user's machine and the remote target host is not aware of the switch. To the legitimate user's machine the connection has "gone-dead". The legitimate user's connection will eventually time-out, or the attacker may try a more sophisticated resynchronization technique when he is done with the hijack.

Part 2 - Analysis of an ARP Spoofing/TCP Hijacking Attack

You are going to use a Linux tool called ettercap to ARP spoof on a network, and hijack TCP connections.

In the lab, set up the following network using the Common Hub:
Figure 1

Start the Windows VM and configure the External adapter according to the specifications above. For this lab we will refer to this VM as the User machine. Make sure you can telnet to bob's account (password: hidden) on the Server from the User. Note that for today's lab every group has a Server with a unique IP.  If each team were to attack the same Server, there is no guarantee that the hijacking sessions will work as designed; at some point one instance of ettercap begins to attack another instance of itself.

Start the Linux VM and open a Terminal.  For this lab we will refer to this VM as the Attacker machine. Configure the External interface according to the specifications above. Recall that during the preamble (Exercise 1) you learned how to identify the external interface.
Confirm your configuration settings by pinging the Server from the Attacker. Also make sure you can observe the telnet traffic between the User and the Server by using tcpdump on the Attacker machine.

Use sudo tcpdump -i external_interface -en on the Attacker machine and/or arp -a on the User machine to identify the correct MAC/IP mappings for each of the 3 machines. Mark these on the diagram.

Now on the Attacker machine start the program ettercap:
You should see ettercap's graphical user interface come up. First, configure the ettercap sniffer by selecting from the main menu: Sniff -> Unified sniffing. In the pop up dialog specify the external network interface.  Then start sniffing by selecting in the main menu: Start -> Start sniffing.

Question: On the User machine run telnet to log into the bob account on the server (if you are already running, logout then login again). Look at the dialog at the bottom of the screen in ettercap on the Attacker machine. What do you see?

Now look at the connection data in ettercap by selecting from the main menu: View -> Connections. You will see a dialog that lists all the connections that ettercap has sniffed (the ones with the star have sniffed account/passwords).  Identify the connection that corresponds to your User telneting to the Server. Double click on this connection; a connection dialog will open. Go back and use your bob account from the User and see what happens on the connection dialog.

Use the ettercap console to browse around and see the following things (have fun, but don't "mitm", "inject data" or  "inject file" yet):
Now we will use ettercap to inject our own commands into the connection. First we need to populate a list of hosts that we can use as targets for our attack. Do this from the Profiles dialog by pressing the "Convert to Host List" button at the bottom of the screen. Then open the Hosts -> Host list dialog. In this dialog select the Server and press the Add to Target 1 button. Then select your User and press the Add to Target 2 button. You can view the targets in the Targets->Current Targets dialog. Now select from the main menu: Mitm -> Arp poisoning... In the ARP poisoning dialog select Sniff remote connections. You should see signs of success status in the dialog at the bottom of the screen.

In the connections dialog you should be able to bring up the connection data dialog for the User telnet session (that is now man-in-the-middled). Type some commands and make sure you can see them sniffed in ettercap.  You can now use the Inject Data button on the bottom of the screen to inject a command into the stream.

Do the TCP hijack again, but capture the traffic using tcpdump. It will probably be best if you redirect the output to a file  (use: sudo tcpdump -i external_interface -en > dumpfile).

Analyze the traffic in your dump file.

Explain:   What has happened to the ARP cache on the Windows VM, use specific examples of ARP cache entries.

Explain:   What packets in your tcpdump trace are associated with the ARP cache poisoning. Note: some are the cache poisoning packets and some may be test packets to see if the spoofing is working. Include parts of your trace as an attachment to your lab submission. (e.g. What is the lie, who is lying , who is the lie effecting)

Explain: Using example packets from your trace explain how the attacking machine is acting as a man-in-the-middle. Pay careful attention to the MAC/IP address correspondence in the packet headers. For example, trace a portion of the telnet session from the legitimate user's machine to the attacker's machine and then to the remote telnet host. Include parts of your trace as an attachment to your lab submission showing the attacker man-in-the-middling the telnet traffic.

Explain:   What packets in your tcpdump trace are associated with the TCP hijack.  Again, pay careful attention to the MAC/IP address correspondence in the packet headers when explaining. Also consider the TCP sequence number issues involved. Include parts of your trace as an attachment to your lab submission showing the injection of your hijacking traffic and how it is passed to the target and the responses from the target.

Conclusion

When you are finished, properly shut down the VMs and log out of the host.

Submit your lab report by e-mail. If you have more than one file place them in a zip file before sending. Don't forget how important the discussion section of the lab is. There are some specific questions in the text above. Ensure that you address these questions in your lab discussion, or address them separately.